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Abstract 

Different  situations  may  require  the  presentation  of 
different  types  of  examples.  For  instance,  some  sit¬ 
uations  require  the  presentation  of  positive  examples 
only,  while  others  require  both  positive  and  nega¬ 
tive  examples.  Furthermore,  different  examples  often 
have  specific  presentation  requirements;  they  need 
to  appear  in  an  appropriate  sequence,  be  introduced 
properly  and  often  require  associated  prompts.  It 
is  important  to  be  able  to  identify  what  is  needed 
in  which  case,  and  what  needs  to  be  done  in  pre¬ 
senting  the  example.  A  categorization  of  examples, 
along  with  their  associated  presentation  requirements 
would  help  tremendously.  This  issue  is  particularly 
salient  in  the  design  of  a  computational  framework  for 
the  generation  of  tutorial  descriptions  which  include 
examples.  Previous  work  on  characterizing  exam¬ 
ples  has  approached  the  issue  from  the  direction  of 
when  different  types  of  examples  should  be  provided, 
rather  than  what  characterizes  the  different  types.  In 
this  paper,  we  extend  previous  work  on  example  char¬ 
acterization  in  two  ways:  (i)  we  show  that  the  scope 
of  the  characterization  must  be  extended  to  include 
not  just  the  example,  but  also  the  surrounding  con¬ 
text.  and  (ii)  we  characterize  examples  in  terms  of 
three  orthogonal  dimensions:  the  infonnation  con¬ 
tents  the  intended  audience,  and  the  knowiedge  type. 
We  present  descriptions  from  text-books  on  lisp  to 
illustrate  our  points,  and  describe  how  such  catego¬ 
rizations  can  be  effectively  used  by  a  computational 
system  to  generate  descriptions  that  incorporate  ex¬ 
amples. 

Introduction 

It  has  long  been  known  that  example.*  are  very  useful  in 
communication  -  especially  in  explanations  and  instruc¬ 
tion.  New  ideas,  concepts  or  terms  are  conveyed  with 
greater  ease  and  clarity  if  the  descriptions  are  accompa¬ 
nied  by  appropriate  examples  (e.g.,  (Iloutz  et  ai,  1973; 
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Ames  grant  NCC  2-520  and  DARPA  contract  DABT63-91-C- 
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A  liai  always  begris  with  a  lelt  paranihesis  Than  coma  zero 
or  mora  pieces  o<  data  (called  the  eiemanis  of  the  lisi)  arxl  a 
nght  parenthesis.  :  Some  exarrpies  of  iiM  are;  i 

(AARDVARK)  | 

i  (RED  YELLOW  GREEN  BLUE) 

(2  3  5  11  19)  i 

(3  FRENCH  FRIES) 

A  List  may  contain  other  lists  as  elemanis;  Given  the  three  Nsisi 
(BLUE  SKY)  (GREEN  GRASS)  (BROWN  EARTH)  ; 

:  we  can  make  a  list  by  combining  them  all  with  a  parenthesis; 
((BLUE  SKY)  (GREEN  GRASS)  (BRO)NN  EARTH)) 

Figure  1;  A  description  with  examples. 

MacLachlan,  1986;Pirolli,  199l;Rederefa/.,  1986)).  Fur¬ 
thermore,  people  often  like  examples  because  they  tend  to 
pul  abstract,  theoretical  information  into  concrete  terms 
they  can  understand.  An  important  issue  in  the  use  of  ex¬ 
amples  is  the  ‘suitability’  of  the  example  to  be  presented. 
Previous  studies  on  the  categorization  of  the  ‘suitability’ 
of  different  examples  include:  a  study  by  Polya,  based 
their  intended  use  (Polya,  1945),  and  by  Rissland,  based 
on  the  ‘example  type’  (Michener,  1978).‘  However,  these 
categorizations  did  not  explicitly  take  into  account  the  con¬ 
text  in  which  the  example  was  presented.  Yet,  the  context 
of  an  example  affects  its  characterization  and  usefulness. 
In  this  paper,  we  shall  describe  a  different  categorization 
of  examples:  one  which  takes  into  account  the  example’s 
surrounding  context  and  can  be  described  in  terms  of  three 
orthogonal  dimensions.  We  also  show  how  this  categoriza¬ 
tion  can  be  useful  to  an  intelligent  luioring  system,  which 
can  then  utilize  this  knowledge  to  prune  large  amounts 
of  its  search  space  in  looking  for  appropriate  examples  to 
present. 

Fur  example,  f-'ipure  1  shows  the  description  of  the 
LISP  concept  list.  The  highl.feiiteu  regions  mark  the 
portions  which  are  generated  because  examples  are  in¬ 
troduced.  Ttie  (irsi  highlighted  portion,  contains  some 

'Rissland  has  published  as  'l-dwina  Rissland'  and  'Edwina 
Rissland  Michener.'  so  references  to  Rissland  may  show  up  dif¬ 
ferently,  as  [Rissland  . , .  ]  or  (Michener . . .  [, 
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introductory  text  before  presenting  four  examples  that  are 
meant  to  convey  information  about  the  different  types  of 
elements  that  can  be  in  a  list.  These  examples,  there¬ 
fore,  end  up  replacing  textual  information  that  would  have 
conveyed  the  same  information.  The  second  highlighted 
portion  contains  both  text  and  some  examples  that  serve 
as  background  for  the  presentation  of  the  actual  example, 
which  is  ((BLUE  SKY)  (GREEN  GRASS)  (BROWN 
EARTH ) ) .  It  is  thus  clear  that  the  introduction  of  exam¬ 
ples  affects  both  the  descriptive  parts  of  the  explanation 
and  the  other  examples  in  different  ways. 

There  are  many  issues  that  must  be  considered  in  select¬ 
ing  and  presenting  examples  (Mittal  and  Paris,  1992).  In 
this  paper,  we  address  the  issue  of  characterizing  the  type 
of  examples  that  appear  in  tutorial  desaiptions,  as  this  can 
help  a  system  in  choosing  appropriate  examples  to  present. 
In  the  following  sections,  we  describe  previous  work  on 
categorizing  example  types,  and  illusuate  how  the  same 
example  can  be  categorized  in  two  different  categories  if 
the  accompanying  description  is  not  taken  into  account. 
Finally,  we  present  our  categorization,  taking  into  consid¬ 
eration  the  surrounding  context  of  the  examples. 

Previous  Work  on  Categorizing  Examples 

A  very  wide  variety  of  examples  can  be  potentially  used 
to  illustrate  any  given  point.  However,  not  all  examples 
are  equally  effective  in  all  situations;  some  are  better  than 
others  in  specific  contexts,  and  others  tend  to  illustrate 
different  aspects  of  the  same  concept  in  different  ways  and 
achieve  different  goals.  Categorizing  examples  is  useful 
because  identifying  a  category  from  which  to  generate 
an  example  can  greatly  consuain  the  number  of  possible 
examples  that  can  be  applicable  in  the  given  situation. 

Polya  categorized  examples  into  three  categories  (Polya, 
1945);  (0  leading  examples,  (it)  suggestive  examples,  and 
{Hi)  counter  examples.  These  categories  were  defined  in 
the  context  of  instruction.  Leading  examples  were  ones 
that  contained  mostly  critical^  features  and  very  few  “ir¬ 
relevant  features;”  they  were  meant  for  naive  users.  Sug¬ 
gestive  examples  contained  more  variable^  features  than 
leading  examples  and  were  meant  to  “guide  the  student 
in  the  correct  direction.”  Counter-examples  were  negative 
examples  that  illustrated  how  instances  were  not  indicative 
of  some  concept. 

In  her  work,  Rissland  categorized  examples  into  five 
categories  (Michener,  1978;  Michener,  1977):  (i)  intro¬ 
ductory  examples:  perspicuous,  simple  cases,  (ri)  model 
examples:  general,  paradigmatic  cases,  (rii)  reference  ex¬ 
amples:  standard,  ubiquitous  cases,  (it;)  counter  exam¬ 
ples:  limiting,  falsifying  cases,  and  (u)  anomalous  exam¬ 
ples:  exceptional,  pathological  cases. 


^Critical  features  are  features  that  are  necessary  for  an  exam¬ 
ple  to  be  consideiwJ  a  positive  example  of  a  concept.  Changes  to 
a  critical  feature  cause  a  positive  example  to  become  a  negative 
example. 

^Variable  features  are  features  that  can  vary  in  a  positive 
example.  Changes  to  variable  features  creates  different  positive 
examples. 


We  believe  that  both  categorizations  suffer  from  two 
problems:  (!)  they  do  not  explicitly  take  into  account  the 
context  of  the  presentation,  and  the  same  example  can  often 
be  classified  into  different  categories,  (it)  the  definition  of 
the  category  is  not  clearly  specified:  it  is  therefore  difficult 
to  implement  in  a  computational  system.  Furthermore, 
the  two  categorizations  above  did  not  specify  relationships 
(if  any)  between  their  different  categories,  nor  did  they 
specify  whether  these  categories  were  mutually  exclusive. 

The  Necessity  for  Categorizing  Examples 
based  on  the  Context 

Our  categorization  of  examples  was  driven  by  the  need 
to  be  able  to  generate  tutorial  and  explanatory  descrip¬ 
tions  that  integrate  examples  coherently  in  a  computational 
framework.*  In  such  a  framework,  the  system  must  be  able 
to  select  (or  generate)  suitable  examples  that  can  illustrate 
the  points  the  system  needs  to  communicate  in  the  expla¬ 
nation  or  in  the  definition  being  presented  to  the  user.  The 
suitability  of  an  example  is  usually  determined  in  the  con¬ 
text  it  appears  in.  rather  than  in  the  abstract:  it  depends 
upon  the  goal  of  the  description,  what  features  are  being 
presented,  where  in  the  overall  description  the  example 
appears,  etc. 

Furthermore,  the  suitability  of  the  example  is  also  af¬ 
fected  by  other  examples  around  it.  A  number  of  studies 
on  the  cognitive  effectiveness  of  examples  have  shown  that 
the  presentation  order  of  the  examples  plays  an  importara 
role  in  user  comprehension  (e.g.,  (Litchfield  el  at..  1990; 
Park  and  Tennsyon,  1986)).  Thus,  the  appropriateness  of 
one  example,  presented  for  the  same  description,  can  be 
different,  based  on  other  examples  that  appear  with  it,  and 
where  it  appears.  It  is  therefore  obvious  that  an  example 
can  be  categorized  only  in  conjunction  with  the  context  in 
which  it  appears. 

We  shall  now  describe  the  three  dimensions  along  which 
we  characterize  an  example  in  context:  the  relationship  of 
the  information  in  the  example  to  that  in  the  context,  the 
intended  audience  of  the  example,  and  the  knowledge  type 
being  communicated  by  the  examples. 

The  First  Dimension:  The  relationship  between 
the  example  and  the  description 

One  of  the  dimensions  that  an  examplecan  be  characterized 
along  is  the  relationship  of  the  information  contained  in  the 
example  with  the  information  contained  in  the  accompa¬ 
nying  descriptive  explanation  that  it  illustrates.  Along  this 
dimension,  an  example  can  fall  into  three  categories: 

1.  Positive  Examples:  These  examples  are  instances  of  the 
concept  being  described  and  satisfy  the  properties  of  the 
concept  as  de.scribed  in  the  accompanying  description. 
These  examples  must  possess  all  the  critical  features 
of  the  concept  they  illustrate.  Such  examples  play  a 


‘Further  detail-  oii  this  work  on  the  design  anu  unpie- 
mentation  of  a  natural  language  system  capable  of  integrat¬ 
ing  examples  and  text  can  be  seen  in  (Mittal  and  Paris.  1992: 
Mittal  and  Paris.  1993). 


supportive  or  elaborative  role  to  the  information  in  the 
description. 

2.  Negative  Examples:  Negative  examples  (or  counter¬ 
examples)  are- not  instances  of  the  concept  being  de¬ 
scribe.  These  are  cases  that  do  not  meet  the  require¬ 
ments  specified  in  the  accompanying  description,  and 
they  play  a  contrastive  role  in  the  context.  Negative 
examples  can  be  very  useful,  because  they  help  rule  out 
non-critical  features  of  a  concept  (Houtz  et  ai,  1 973). 
For  instance,  the  following  pair  of  examples 

(AARDVARK)  ;  exeunple  of  a  list 
AARDVARK  ;  not  a  list 
about  the  concept  of  a  list  in  the  programming  lan¬ 
guage  LISP  illustrate  the  need  for  parentheses  in  a  1  i  st . 
Thus,/(?arunes  in  common  between  positive  and  negative 
examples  can  be  ruled  out  as  suf^ient  features,  while 
differing  features  are  highlighted  as  necessary  and  thus 
become  more  important. 

3.  Anomalous  Examples:  Anomalous  examples  represent 
irregular  or  exceptional  cases.  These  are  either:  (i)  in¬ 
stances  of  the  concept  described,  but  not  covered  by  the 
description,  or  (ii)  those  are  likely  to  be  mis-classified  by 
the  user  (because  of  an  incomplete  description).  Thus, 
positive  instances  which  appear  to  be  very  different  from 
other  positive  examples,  or  negative  instances  which  ap¬ 
pear  to  be  very  similar  to  positive  examples,  would  be 
classified  as  anomalous  cases. 

The  classihcation  of  an  example  into  either  of  these 
categories  depends  upon  the  context  established  by  the  ac¬ 
companying  descriptive  explanation.  As  mentioned  pre¬ 
viously,  it  is  possible  that  an  example  which  would  be 
classified  as  an  anomalous  example  in  one  context  could 
be  classified  as  a  normal,  positive  example  in  another  con¬ 
text.  Consider  the  following  desaiption  of  a  list  in 
LISK 

A  left  parenthesis  followed  by  zero  or  more  S- 
expressions  followed  by  a  right  parenthesis  is  a  list. 

(From  (Shapiro,  1986)) 
Given  the  above  definition  of  a  list,  the  following  ex¬ 
ample  would  classify  as  a  positive  example: 

(1  2  3  4  5  67) 

and  the  following  would  be  a  negative  one: 

1234567 

However,  the  following  examples  would  be  anomalous 
cases,  because  they  are  not  covered  by  the  definition  pre¬ 
sented  above: 

NIL  ;  the  list  NIL 

(a  .  b)  ;  examples  of  a  dotted-list 
This  categorization  of  examples  would  change,  with  an¬ 
other  definition: 

A  list  is  a  coNS-cell  whose  cdr  is  either  the  atom 
NIL  or  another  list.  The  atom  NIL  is  the  identifier  that 
represents  the  empty  list  and  the  boolean  concept 

FALSE. 

(Steele  Jr..  1984)) 

In  this  case.  ItlL  becomes  a  positive  example  of  a  list. 
Similarly,  a  list  may  be  so  defined  as  to  include  the 
concept  of  a  dotted-list  as  well. 


It  is  clear  that  it  is  difficult,  and  sometimes  impossible, 
to  classify  an  example  as  belonging  to  a  certain  category 
without  taking  into  consideration  the  surrounding  contex¬ 
tual  information.  It  is  also  difficult  to  categorize  examples 
as  being  ‘suggestive’  or  ‘model’  or  ‘reference’  without 
having  a  complete  definition  of  these  different  categories. 
It  is  also  not  possible  to  label  an  example  ‘positive’  or 
‘negative’  without  knowing  the  definition  it  is  supposed 
to  illustrate  (AARDVARK  is  positive  example  of  an  atom, 
but  is  a  negative  example  of  a  list).  In  addition,  an 
example  that  is  ‘anomalous’  in  one  context  can  classify  as 
a  positive  example  in  another  context.  Correct  classifica¬ 
tion  of  the  examples  is  essential,  because  examples  must 
be  presented  in  accordance  with  the  category  they  hap¬ 
pen  to  classify  in.  For  instance,  anomalous  examples  can 
cause  great  confusion  in  an  introductory  user  if  presented 
along  with  other  positive  examples.  Anomalous  examples 
should  be  treated  as  such  (presented  separately  from  the 
regular  examples,  with  a  suitable  introduction  to  notify  the 
user  of  the  anomalous  nature  of  such  examples). 

The  Second  Dimension:  The  intended  audience 

The  second  dimension  that  examples  can  be  characterized 
along  is  dictated  by  the  intended  audience  type  of  the  pre¬ 
sentation.  This  is  an  important  consuaint  on  the  selection 
of  information  to  be  presented  both  in  the  description  and 
the  example.  There  have  been  many  studies  on  the  need 
for  varying  both  the  amount  of  information  and  the  manner 
of  its  presentation,  based  on  the  user  (e.g.,  (London.  1992; 
Yoder,  1986;  Paris,  1988)).  These  studies  have  demon¬ 
strated  that  there  are  significant  differences  in  descriptions 
and  examples  meant  for  different  user  types. 

As  we  have  already  mentioned  before,  the  major  short¬ 
coming  of  both  the  previous  example  categorizations  was 
due  to  the  fact  that  they  did  not  take  the  accompanying 
context  into  account.  In  contrast,  we  consider  both  the 
description  and  the  example  for  categorization.  This  is 
essential  in  our  case,  because  the  system  needs  to  gen¬ 
erate  both  the  text  as  well  as  the  example  in  its  expla¬ 
nation.  Often,  even  though  the  examples  tend  to  look 
alike,  the  accompanying  descriptions  are  very  different  for 
different  user  types.  For  instance.  Pirolli  found  that  in 
some  domains,  such  as  recursion,  the  examples  presented 
to  both  naive  and  advanced  users  were  almost  identical, 
but  their  explanations  were  very  different  (Pirolli.  1991). 
Feldman  and  Klausmeier  found  similar  differences  in  the 
phrasing  of  definitions  presented  to  fourth  and  eight  grade 
students  (Feldman  and  Klausmeier,  1974). 

From  our  analyses  of  naturally  occurring  texts,  we  have 
classified  examples  (in  the  context  of  their  accompanying 
descriptions)  into  three  main  classes  -  introductory,  inter¬ 
mediate  and  advanced.  This  classification  consuains  the 
content  and  the  presentation  style  of  the  descriptions  and 
the  examples  used  with  them: 

1 .  introductory:  -  users  with  little  or  no  previous  exposure 
assumed  for  the  concept;  goal  is  to  learn  about  the 
concept, 

2.  intermediate:  -  users  with  moderate  previous  exposure: 
goal  is  to  learn  to  make  use  of  the  concept. 


3.  advanced:  -  users  with  extensive  luiowledge;  goal  is  to 

clarify  some  point  or  misconception  about  Lhe  concept. 
Introductory  Users:  Examples  in  in¬ 

troductory  descriptions^  tend  to  be  simple  ones  -  whae 
‘simple’  refers  to  the  fact  that  they  are  usually  single- 
featured  (or  if  they  have  multiple  features,  sometimes  two. 
where  the  two  features  are  along  two  different  feature  di¬ 
mensions).  In  our  domain  of  lisp  descriptions,  the  ac¬ 
companying  description  is  syntactic  or  surface/appearance 
oriented.  Anomalous  examples  are  usually  absent,  and 
if  they  are  presented,  they  are  done  so  after  ail  the  other 
examples.  Examples  are  often  ir.L’'oduced  as  soon  as  the 
point  they  illustrate  is  mentioned  in  the  text. 

Consider  for  instance  the  description  in  Figure  1.  The 
descriptions  are  centered  around  the  syntax  or  the  surface 
appearance  of  the  list.  The  examples  are  simple  and 
illustrate  a  feature  at  a  time  (the  type  of  data  elements, 
exc^t  in  one  case  where  the  type  and  the  number,  two  dif¬ 
ferent  dimensions  of  variation,  are  illustrated).  Examples 
do  not  always  have  prompts,^  because  the  same  informa¬ 
tion  is  often  realized  as  sentences  in  the  accompanying 
description. 

Intemicdiate  Users:  Descriptions  written  for  the  ‘inter¬ 
mediate’  user  (who  is  already  assumed  to  have  introduc¬ 
tory  knowledge)  tend  to  be  more  complex  than  the  ones 
for  introductory  users,  in  that  they  include  more  detail  on 
how  the  information  may  be  used  by  the  user.  The  ex¬ 
amples  are  not  always  presented  immediately;  if  there  are 
a  number  of  related  points,  these  points  are  stated  first, 
before  a  group  of  examples  illustrating  these  points  are 
presented.  The  examples  themselves  are  usually  briefly 
annotated  (with  prompts).  Intermediate  descriptions  con¬ 
tain  a  few  introductory  examples,  which  are  then  followed 
by  typical  uses  of  such  example  instances,  which  contain 
mostly  multi-featured  examples.  For  example,  the  de¬ 
scription  in  Figure  2  describes  how  a  list  can  be  used 
to  represent  shopping  lists,  store  phone  numbers  and  write 
function  calls. 

Advanced  Users:  Since  the  purpose  of  advanced  or  ref¬ 
erence  materials  is  not  instruction,  it  is  not  surprising  that 
both  the  textual  description  and  the  accompanying  exam¬ 
ples  are  very  different  from  those  in  the  introductory  ones. 
The  documenution  and  the  examples  usually  occur  in  a 
fixed  format,  with  the  examples  following  the  definition 
and  the  explanation.  The  examples  are  not  simple,  single- 
featured,  but  tend  to  be  few  and  multi-featured  (typically 
three  to  four  features).  The  examples  are  often  almost 
independent  of  the  textual  description,  with  little  cross- 
referencing  between  the  two.  This  almost  invariably  re¬ 
sults  in  prompts  being  used  to  indicate  some  of  the  salient 
characteristics  of  the  examples.  Since  the  descriptions  lend 
to  be  comprehensive,  there  are  few  (if  any)  anomalous  ex- 


’We  shall  use  tenns  such  as  •introductory  descripiions'  to 
indicate  descriptions  meant  for  an  introductory  audience. 

‘‘Prompts'  are  additional  text  or  markers  associated  with  ex¬ 
amples  to  draw  attention  to  specific  features  in  the  examples  (En- 
gelinann  and  Gamine.  1982). 


A  list  looks  like  a  sequence  ol  objects,  without  commas  between 
them,  enclosed  in  parentheses. 

Appropriately  constructed  lists  can  also  be  used  to  call  functions 
in  LISP.  If  you  type  any  of  the  lists  in  table  2-4  to  LISP,  you  will 
get  an  appropriate  response. 

Table  2-2: 

(12345)  ;  List  of  numoers 

(A  B  C  D)  ;  List  of  syrr.tao.s 

(#\A  #\B  #\C  tt\D)  ;  List  of  characte-s 

Table  2-3; 

(This  is  (also)  a  list! 

("this  is  cl  stri.ig  in  a  list"  -53, 

((Beth  ■555-5834-1  (Pat  ■5b5-8098- 
Table  2-4 : 

(SQRT  2) 

{<■  2  3) 

( -  6  5  4 ) 

Lists  can  be  considered  ways  to  store  data.  For  example,  you 
might  want  to  store  your  inventory  as  a  list  or  group  together 
names  and  phone  numbers  In  a  list 

Figure  2:  Intermediate  descripiions  with  ‘use'  oriented 
examples  from  (Tatar,  1987),  p.  16. 

A  list  is  recursively  defined  to  be  either  the  empty  list  or  a 
CONS  whose  CDR  component  is  a  1  ist.  The  CAR  components 
of  the  CONSes  are  called  the  elements  of  the  list  For  each  element 
of  the  list  there  is  a  CONS.  The  empty  list  has  no  elements  at  all. 
A  list  is  annotated  by  writing  the  elements  of  the  list  in  order, 
separated  by  blank  space  (space,  tab.  or  return  character)  and 
surrounded  by  parentheses.  For  example; 

(abc)  ;Alistof3  symbols 

(2.0s0  (a  1)  #\*)  ;  A  list  of  3  thingsia 

;  float,  a  list,  and  a 
;  character  object 

The  empty  list  NIL  therefore  can  be  written  (  ),  because  it  is  a 
list  with  no  elements. 

From  (Steele  Jr.,  1984),  p.26 

Figure  3:  Reference  documentation  is  complete  and  tends 
to  have  few  (multi-featured)  examples. 


amples.  If  there  are  any  anomalous  examples,  they  are 
always  presented.  For  example,  a  description  of  a  list 
from  an  advanced,  reference  manual  is  shown  in  Figure  3. 


The  Third  Dimension:  The  Knowiedge-TVpe 

In  addition  to  the  user-type  and  the  example-type  which  can 
be  used  to  consuain  the  possible  choices  that  need  to  be 
made  in  generation,  the  knowledge-type  can  also  be  used 
during  the  generation  process  to  determine  the  appropriate 
type  and  sequence  of  examples  to  be  generated  in  an  ex¬ 
planation.  The  knowledge-type  refers  to  the  categorization 
of  information  into  one  of  three  broad  classes:  concepts, 
relations  ot processes.  There  can  be  significantdifferences 
in  the  presentation  of  examples  and  the  accompanying  de- 


The  list  function  takes  any  number  of  inputs  and  makes  a 
list  of  them  all.  For  example: 


INPUT  to  list 

OUTPUT 

Too  ‘bar  ‘baz 

(foo  bar  baz) 

Too 

— 

(foo) 

‘sun  NIL 

— 

(sun  NIL) 

’(frob) 

((frob)) 

From  (Touretzky,  1 984),  p.5 1 

Figure  4;  Examples  of  relations  focus  on  the  items  being 
related. 


scriptions  based  on  whether  the  idea  to  to  be  explained  is 
a  concept,  relation  or  a  process. 

Consider  for  instance  the  concept  ‘list’  (as  described  in 
Figure  l)and  thtnlation  ‘list’  (functions  are  relations  that 
hold  between  the  input  parameters  and  the  output  values 
of  the  function),  as  described  in  Figure  4. 

The  concept  list  is  described  as  an  object,  and  examples 
of  list  are  instances  which  exemplify  the  term  ‘list’:  the 
function  list,  on  the  other  hand,  is  described  in  terms  of  its 
input  and  output  parameters,  and  examples  of  the  function 
reflect  this  fact.  Similarly, processes,  which  are  sequences 
of  functions  are  described  differently  and  their  examples 
are  often  instances  of  function  parameters  at  every  step  in 
the  sequence.  In  generating  examples  of  relations,  it  is  im¬ 
portant  to  keep  in  consideration  that  the  examples  used  as 
input-output  parameters  must  be  known  to  the  hearer.  The 
system  must  also  be  careful  to  choose  examples  which  are 
not  anomalous  or  exceptional  cases  for  these  parameters. 

Examples  of  processes  consist  of  chains  of  events  that 
take  place  in  a  particular  order.  The  goal  is  to  communicate 
the  sequence  of  events  and  their  cumulative  effect.  As  in  the 
case  of  examples  of  relations,  the  system  must  ensure  that 
all  the  concepts  and  relations  needed  to  present  a  process 
example  are  known  to  the  user  before  the  process  example 
is  presented. 

Discussion 

The  three  dimensions  along  which  we  categorize  examples 
are  not  limited  to  the  gradations  that  we  have  mentioned 
in  this  paper.  In  our  framework,  there  are  yet  finer  grada¬ 
tions  which  are  used  by  the  system  in  making  decisions. 
For  instance,  concepts  are  further  sub-divided  into  whether 
they  are  single-featured,  multiple-featured,  or  comparati  ve 
concepts.  These  finer  gradations  allow  us  to  make  better 
decisions  about  both  the  number  of  examples  as  well  as 
their  presentation  order  in  our  system.  Figure  5  shows  a 
representation  of  the  three  dimensions  in  this  categoriza¬ 
tion. 

Applications  to  the  Generation  of  Tutorial 
Descriptions 

The  categorization  of  examples  (in  the  context  of  their 
accompanying  description)  that  we  have  outlined  is  ex¬ 
tremely  useful  in  constructing  a  system  for  generating  tu¬ 
torial  descriptions.  (3ur  major  goal  is  not  just  the  selection 
(or  generation)  of  appropnate  examples  by  themselves. 


Figure  5:  The  three  dimensions  along  which  examples  can 
be  categorized  in  context. 


but  the  generation  of  a  description  that  integrates  exam¬ 
ples  and  text  in  an  effective  manner.  This  requirement 
brings  up  many  issues  that  may  otherwi.se  be  not  consid¬ 
ered  as  important:  issues  such  as  the  interaction  between 
the  examples  and  the  description  (how  the  text  changes 
because  of  the  presence  of  examples),  the  placement  of  the 
examples  in  relation  to  the  explanation  (before,  within  or 
after  the  description),  etc. 

Our  current  framework  implements  the  generation  of 
examples  within  a  text-generation  system  by  explicitly 
posting  the  goals  of  providing  examples.  Our  system 
uses  a  planning  mechanism;  given  a  top  level  commu¬ 
nicative  goal  (such  as  ( DESCRIBE  LIST)  ) ,  the  system 
finds  plans  capable  of  achieving  this  goal.  Plans  typically 
post  further  sub-goals  to  be  satisfied,  and  planning  contin¬ 
ues  until  primitive  speech  acts  -  i.e.,  directly  realizable  in 
English  -  are  achieved.  The  result  of  the  planning  pro¬ 
cess  is  a  discourse  uee,  where  the  nodes  represent  goals 
at  various  levels  of  abstraction  (with  the  root  being  the 
initial  goal,  and  the  leaves  representing  primitive  realiza¬ 
tion  statements,  such  as  (INFORM  . .  . )  statements.  In 
the  discourse  uee,  the  discourse  goals  are  related  through 
coherence  relations.  This  uee  is  then  passed  to  a  gram¬ 
mar  interface  which  converts  it  into  a  set  of  inputs  suitable 
for  input  to  a  natural  language  generation  system  (Pen¬ 
man  (Mann,  1983)).  Examples  are  generated  by  explic¬ 
itly  posting  a  goal  within  the  text  planning  system:  i.e., 
some  of  the  plan  operators  used  in  the  system  include  the 
generation  of  examples  as  one  of  their  steps,  when  appli¬ 
cable.  This  ensures  that  the  examples  embody  specific 
information  that  either  illustrates  or  complements  the  in¬ 
formation  in  the  accompanying  textual  description.  Issues 
such  as  the  number  of  examples  to  be  presented,  the  order 
in  which  they  should  be  presented,  whether  they  should 
have  prompts  associated  with  them,  etc.  can  then  be  de¬ 
termined  in  conjunction  (using  the  constraints  imposed  on 
the  selection)  with  the  categorization  of  the  examples  to 
be  presented.  Associated  with  each  gradation  in  our  cat¬ 
egorization,  we  have  specific  presentation  heuristics  for 
the  examples  and  their  descriptions.  The  resulting  dis¬ 
course  structure  is  then  processed  to  make  final  decisions, 
such  as  the  choice  of  lexical  items.  Finally,  the  completed 


discourse  tree  is  passed  to  a  a  system  that  converts  the 
INFORM  goals  into  an  intermediate  form  that  is  accessible 
'  to  Penman,  which  generates  the  desired  English  output. 

Conclusions 

The  categorization  of  examples,  along  with  specific  guide¬ 
lines  of  when  and  how  different  types  of  examples  should 
be  presented  is  an  extremely  important  issue  in  the  design 
of  an  intelligent  tutoring  system.  Our  categorization  is  a 
generalization  of  the  previous  work  by  Rissland  and  Polya, 
and  extends  the  scope  of  the  characterization  to  take  into 
account  the  surrounding  context  of  the  example.  The  cat¬ 
egories  along  each  of  the  three  dimensions  that  we  have 
mentioned  are  only  meant  to  illustrate  how  they  affect  the 
examples  and  the  text  to  be  presented.  These  categories 
can  be  sub-divided  further  into  smaller  classes  and  specific 
presentation  methods  can  be  associated  with  each  class. 

We  have  implemented  a  system  that  plans  the  presen¬ 
tation  of  coherent  text  and  examples.  The  plan  operators 
(which  select  information  to  be  presented),  also  make  use 
of  the  information  along  the  user-type  and  the  knowledge- 
type  dimensions  to  structure  the  content  as  well  as  the 
surface  form  of  the  description  appropriately.  Thus,  the 
characterization's  modular  nature  allows  the  represented 
information  to  be  shared  among  different  resources  in  the 
system. 
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